Add StaggeredUpdateTracker for tick spreading#6634
Conversation
Add an entity system helper designed to be used where a component is updated on a regular interval greater than one tick, with updates intended to be spread across multiple ticks. This is intended to replace several places today where content records a next update field on a component, then iterates all entities every tick checking to see if it is time to update that component. The implementation in this commit efficiently keeps a sorted schedule of updates and allows the entities due to update (and only those entities) to be enumerated in amortized constant time for each. Removed components are handled lazily, and new components are handled via a priority queue. The schedule itself is implemented as a ring buffer. A limitation of the approach is that the update interval cannot vary across individual instances of tracked components.
|
Any chance for a implementation that doesn't register on the MapInitEvent? if this does get merged i'd like to use it but i see that restriction being a issue (unless im wrong and engine/content have split bus events that don't conflict) |
|
What use case do you have in mind? The If this were implemented as an abstract entity system it could also be made to work something like Do you have a use case that isn't covered by those? Where you'd for some reason want manual control over addition and removal instead of having it track component lifecycle? |
2 participants
Add an entity system helper designed to be used where a component is updated on a regular interval greater than one tick, with updates intended to be spread across multiple ticks. This is intended to replace several places today where content records a next update field on a component, then iterates all entities every tick checking to see if it is time to update that component.
The implementation in this commit efficiently keeps a sorted schedule of updates and allows the entities due to update (and only those entities) to be enumerated in amortized constant time for each. Removed components are handled lazily, and new components are handled via a priority queue. The schedule itself is implemented as a ring buffer.
A limitation of the approach is that the update interval cannot vary across individual instances of tracked components.